Oct 92 May 93 <draft-ietf-hostmib-resources-01.txt>
Host Resources MIB
IEEE 802.3 Hub MIB (hubmib)
---------------------------
Charter
Chair(s):
Keith McCloghrie <kzm@hls.com>
Donna McMaster <mcmaster@synoptics.com>
Network Management Area Director(s)
Marshall Rose <mrose@dbc.mtview.ca.us>
Mailing lists:
General Discussion:hubmib@synoptics.com
To Subscribe: hubmib-request@synoptics.com
Archive: sweetwater.synoptics.com"~/pub/hubmib
Description of Working Group:
This Working Group will produce a document describing MIB objects for
use in managing Ethernet-like hubs. A hub is defined as a multiport
repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s
Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd
edition, Sept. 1990). These Hub MIB objects may be used to manage
non-standard repeater-like devices, but defining objects to describe
vendor-specific properties of non-standard repeater-like devices are
outside the scope of this Working Group. The MIB object definitions
produced will be for use by SNMP and will be consistent with other SNMP
objects, conventions, and definitions.
In order to minimize the instrumentation burden on managed agents, the
MIB definitions produced by the Working Group will, wherever feasible,
be semantically consistent with the managed objects defined in the IEEE
draft standard P802.3K, ``Layer Management for Hub Devices.'' The
Working Group will base its work on the draft that is the output of the
July 1991 IEEE 802 plenary meeting. The Working Group will take
special cognizance of Appendix B of that specification that sketches a
possible realization of the relevant managed objects in the SNMP
idiom.
Consistent with the IETF policy regarding the treatment of MIB
definitions produced by other standards bodies, the Working Group may
choose to consider only a subset of those objects in the IEEE
specification and is under no obligation to consider (even for
``Optional'' status) all objects defined in the IEEE specification.
Moreover, when justified by special operational needs of the community,
the Working Group may choose to define additional MIB objects that are
not present in the IEEE specification.
Although the definitions produced by the Working Group should be
architecturally consistent with MIB-II and related MIBs wherever
possible, the Charter of the Working Group does not extend to
perturbing the conceptual models implicit in MIB-II or related MIBs in
order to accommodate 802.3 Hubs. In particular, to the extent that the
notion of a ``port'' in an 802.3 Hub is not consistent with the notion
of a network ``interface'' as articulated in MIB-II, it shall be
modelled independently by objects defined in the Working Group.
Because the structure of 802.3 Hub implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of Hub management rather
than the structure of particular Hub implementations.
The IEEE Hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable unites as groups of ports so that the port numbering would match a modular hardware implementation.) Because the Working Group Charter
does not extend to consideration of fault-tolerant, highly-available systems
in general, its treatment of these groups of ports in an 802.3 Hub (if any)
shall be specific to Hub management and without impact upon other portions of
the MIB.
The Working Group is further chartered at its discretion to define an
SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An
802.3 Medium Attachment Unit (MAU) attaches a repeater port or
Ethernet-like interface to the local network medium. The scope of this
work may include several types of MAU units: 10BASE5 (thick coax),
10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber
optic). Managed objects defined as part of the MAU MIB task may, for
example, represent such information as MAU type, link status, and
The PIP Working Group is chartered to develop an IPv7 proposal using
the basic ideas of Pip as described in the Pip overview.
Pip is designed on one hand to be very general, being able to handle
many routing/addressing/flow paradigms, but on the other hand to allow
for relatively fast forwarding. Pip has the potential to allow for
better evolution of the internet. In particular, it is hoped that we
will be able to advance routing, addressing, and flow techniques
without necessarily having to change hosts (once hosts are running
Pip).
While the Pip overview demonstrates a number of powerful mechanisms,
much work remains to be done to bring Pip to a full specification.
This work includes, but is not limited to: specifying the header
format; specifying a basic set of error messages (PCMP messages);
specifying the Pip forwarding rules; specifying host interface messages
(particularly the directory service query response); specifying rules
for host Pip header construction; specifying modifications to existing
protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying
Pip MAX MTU Discovery techniques; and specifying a transition strategy
for Pip.
Over the near-term, the goal of the PIP Working Group will be to produce these
specifications and supporting documentation. Over the long-term, up to
the point where Pip is definitively rejected as IPv7, it is expected
that the PIP Working Group will oversee implementations and testing of the Pip
specifications.
Except to the extent that the PIP Working Group modifies existing protocols for
operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the
PIP Working Group will not work on routing/addresing/flow architectures.
